Quote from T3charmy :

only thing i wish, was on OBH and HLV that it is actual speed not closing speed...

If I see correctly, HLV has no speed, only CON and OBH have it. And, maybe I am too tired, but what use would be the actual speed? The closing speed describes impact severity, which seems to be the perfect measure of contacts with other cars and objects.

Quote from EQ Worry :

PS: I guess the demo/tweaked/private bits of server state did not make it to your intended features list?

I wonder if this could be one of the last-minute small updates for the official patch. I promise, this is the last time I mention it, also I have no more ideas/requests (well, for this patch at least).

Now I remember a long-existing thing, the "unknown car id" displayed sometimes. I wonder if that could be related to the fact that often cars are send to /spec right after pitting (Shift+P) by InSim apps, e.g. to prevent repeated midrace rejoins from pits. Maybe a small lag would cause some LFS pitting routine to be delayed for so long that when it runs the car is not in the pits anymore, but spectating? Just an idea though.

Again, thanks for all the updates!

Alright.

Quote from Scawen :

I hope Airio and other InSim programs do handle split packets.

Uhmmmm... I'll take a look at the way this is done and will consult it with a professional programmer, who's also working on the library, thanks for info.

Thinking about it, I'm not sure making that admin command packet type optional is a solution either. After all there are the new car hit packets and maybe also other ones that are simply sent. It seems everyone wanting to use Airio with new patch will have to update... Maybe a switch to activate version 5 packets? Uhm, I'd want too much I guess...

Hm, then it would seem LFS is sending those hit packets, even though it should not? Or maybe I misread something somewhere. Automatic track/car change is done using admin commands, so yes, that would lead to disconnect. Please try to use the updated library.

Well, yeah, I'm trying to explain this weird approach in a bit more detail here.

Quote from Scawen :

Is there any reason why Aririo closes if it gets an unknown packet? I think all InSim programs should simply ignore unknown packets, if their size is valid, just skip it and carry on.

Well, yeah, a bit short-sighted decision. But in the past 2.5 years all unknown InSim packet types, as well as incorrect packet sizes meant just one thing: Broken (usually remote) communication. When one bad packet comes, many others always follow, and even those that look OK are in fact wrong, so disconnecting on each bad packet and auto-reconnecting the InSim app a minute later was the best and safest I could do. I think even for the future, just skipping bad packets will not work, because they mean some serious connection troubles and unreliable data. Well, that's just my experience...

PS: Also, bad packet received means some data, possibly important ones, were sent but not received and processed which can lead to all kinds of troubles. Again, the safest route is to close it all and restart the connection, getting all the data again. It works pretty well, when the InSim connection is local (server and Airio on one PC), this almost never happens, we've been running several full demo servers for days and weeks without a glitch. But it is kind of a safety measure to stop faulty communication.

Last edited by EQ Worry, Sat, 11 Jun 2011 08:13.

Scawen, I have one incompatibility issue, sorry to bother you again. Almost all the new packet types (layout/hit/contact) are optional, requested on InSim connect. The only exception is the ISP_ACR admin command packet, which is always sent. Unfortunately the library I use is detecting it as bad packet type, assuming communication error, leading to disconnect. Maybe a short-sighted assumption, but it worked very well for 2.5 years.

Of course I updated the library and I will think how to make it better future-proof, but all the current Airio versions will cease to function properly after server update to 0.6, which will happen soon, I guess. So, please, is there any chance to make the ISP_ACR packet also optional, that must be required during InSim connect? It would help help a lot now. Thanks for reading.

PS: I guess the demo/tweaked/private bits of server state did not make it to your intended features list?

Last edited by EQ Worry, Sat, 11 Jun 2011 07:24.

Quote from cargame.nl :

I catch some hours sleep now, hopefully Worry has some time this morning to implement an ISP_AXO ignore routine and lets hope for the best.

I believe the only "incompatible" additional packet are the admin commands being reported to InSim. All the other hit/contact/layout packets are optional and not sent in the current Airio versions. Hm, maybe I should ask Scawen (also in the InSim thread) to make it optional as well to keep some compatibility. Anyway, I have updated the library a bit to accept the new packet types.

Actually, if I have all the InSim updates correctly sorted in my head, that warning of unknown packet (and Airio disconnect) happens only after every admin command, both accepted and refused, from any connection. All the object hits and layout update packets are optional and not sent.

Anyway, I did a quick patch of the library to recognize all the new packet types as valid ones, though without processing. Please, anyone interested in testing the incompatible patch 0.6A1 and newer with Airio, download and update the Aegio library files. (I hope it works...)

Yeah, sorry, I guess it is time to update the Aegio library... I'll try to make it today, at least so that all new packet types are known.

InSim libraries will need some serious updates with version 5. Thanks for the admin commands stuff, I already feel safer. Hopefully I could test it toning, to see e.g. what "set if user is an admin" actually means, if this byte just uses 0 and 1...

First, thanks for response! Of course Demo/Licensed status is of no use on licensed hosts, where demo people cannot connect. However, S1 or S2 info could be useful, if only just to see that you can move to an S2 combo without anyone losing connection. However, I would like to use it basically the other way, on demo servers to see who's got a license and can be e.g. invited to an event. Most of the people on demo servers are demoers, nobody's been raising an issue of this for years on our servers, I do not remember a single case when someone was "spitting" on demo people while racing on a demo server. Maybe here in this forum there are some rants occasionally, but I never witnessed problems online. One additional thing: The license status is already actually available, though not 100% exact. You just take a look at the guy's online stats and if more than 5 rows are returned, you know he's got a kind of license. I personally see no big deal in making this info available more readily. It is actually usable only on demo servers where nobody is making fun of demo people. The S1/S2/S3+ state would be handy from server management point of view. Well, and then people may always hide all of their data... PS: Airio is showing the derived status for a really long time already, and I don't think there ever was a problem with it. That Demo/S1/S2 info from LFSW would just make the info more precise and 100% exact.

Last edited by EQ Worry, Thu, 9 Jun 2011 13:57.

Quote from Krammeh :

I would really like to know if a user has DEMO/S1/S2 on join

+1

I guess though that this is more a LFSW matter, it would be great to have this as part of some existing info (personal data - where country, total distance, races, etc. are available).

I'm not sure about tail and grep, but I think it obviously is a kind of makeshift solution, while an InSim message packet (maybe message of special type, we already have about 4) is nice and clean. Also I would guess any "server log change listeners" can work only locally. And even if I'm mistaken in this point, still...

Quote from Scawen :

I have added a line, if logging is enabled and someone connects as an admin ... I'm not sure yet if I'll do this, but I've made a note.

Great, thanks , having it in server log will allow for later diagnosis, but it is not really easy to respond to server log items in real time (though not impossible, under certain circumstances). Having the admin commands, or attempts at them, forwarded to InSim would make things of course much easier. But I'm very happy with this 1st step, thank you. Maybe instead of colon a plus could be used, representing accepted command, while minus represents refused command? Well, whatever, it is not really important, it just seems to be more, uhm, intuitive...

Quote from Scawen :

I guess my question to you is... for the wall collision detection, would you be happy with the same check as HLVC? This is designed to detect bad driving so I'm guessing it is quite suitable for your purposes.

I guess using the same code HLVC uses is absolutely sufficient, as long as it reports substantial touches of walls, cones, etc., maybe also grass/ground if that is possible. Whatever seems simple enough. Thanks.

I do not want to delay official patch, but I hope you noticed some other proposals here concerning InSim and server log, specifically 1) logging/reporting all attempts at using admin commands from all connections, which I consider very important and actually a security hole now, and maybe 2) adding demo/tweak/private bits to server/race state info, sending it all also in the IS_STA packet on every change.

Sorry, I know I mentioned these 2 things twice before, but especially the silent admin commands are really not good and potentially dangerous. For example I know someone got admin rights on our servers without using the pass, very probably somehow after connecting, not during connect (here I have no idea if admin rights are checked by server or clients, if for example server processes all admin commands coming from "approved", possibly hacked clients), but I have no way to track the guy and the commands. Just logging them and reporting them to InSim apps makes major difference with swift action possible.

So again, sorry for repeating this, but...

PS: Oops, I almost forgot: Thanks for the object updates! It all looks very nice, but it would require time to incorporate all the changes and see if everything works smoothly.

OK, qualification mode could be the key to the troubles, I'm almost always in a race mode, so maybe I did not spot the problem. I'll try to take a look at this tomorrow, so please stay tuned, hopefully for an update.

Ouch, hmmm, I see. Can you please describe in more details actions that lead to corrupted data? I guess also Aonio log of such situation would be helpful. It is indeed a nice feature (thx go to Scipy for suggesting it), so definitely I'd like to make it reliable.

Quote from Scawen :

What still needs to be done for the incompatible test patch :
- The actual InSim packets for adding and deleting multiple objects (easy now that the internal packets are done)
- Reporting collisions with objects (should be simple enough now having done some updates for the hotlapping system)

Thanks for the progress info! Sorry if you know about the following already, but I think they are very important things - please, Scawen, before releasing the incompatible patch take also a look into the InSim changes thread, there are a few more suggestions/wishes, hopefully simple ones:

1) Extending server state info by tweaked/private/demo bits, 2) sending the info as part of IS_STA on every update, 3) forwarding all admin commands from all connections to server log as well as to InSim apps maybe as a new type of message, for much improved server control and security.

Last edited by EQ Worry, Sat, 4 Jun 2011 22:32. Reason : Pointing out the most important...

Well, sorry, one more suggestion, extending the server state info data and reporting as already mentioned here: One more bit saying whether or not the server is in demo-compatible mode would be helpful.

I believe it is possible to use /demo=s2 in server config and still make it available to demo people, but that depends on track+cars+connections+layout and it is hard to gather all these data separately. So that one more bit as part of server state (ideally sent on every state change as suggested in the linked post) would be nice.

Thanks!

I'd say the flashlights are annoying enough as they are now...

I believe the individual car blocking is much better than forcing people to spec, as it is done now, so this feature is in every respect (for me) a major improvement. If properly used, it will substantially limit confusion and bad race joining spam happening now.

I hope, Scawen, that you still follow this thread, because I'd like to suggest a security improvement, also related to InSim. Just yesterday and today our servers were hacked in some way. I believe someone connected gained admin rights while being already online, or at least he/she was able to use all server admin commands. (I'm not sure, is that possible?)

The bad thing is that neither server nor any InSim tool (if I'm not mistaken) is able to log/see admin commands entered anywhere else than on host (and Remote, which is the host itself). All the / commands coming from a normal connection are "eaten", never reported. They are either refused or processed, but never logged.

Here I dare to suggest the following:

1) Whenever someone connects with server admin rights (or gets them somehow later, uhm?), record the event into server log, just one line with time, name, status.

2) Store all admin commands into server log, even when they come from normal connections and not just the host. This would be, I think, a major safety improvement allowing to backtrack currently hidden actions of rightful (and fake) admins. Of course I do not know how easy this is to implement, but I hope it can be done. Again, one line in server log, time, name, command, like it was a normal message.

3) If somehow possible, forward all such commands of all the connections also as standard messages to InSim clients, maybe using a new special type of message if necessary (I am not sure). IMO best would be to log/report all such commands, even if they're refused for insufficient rights. The idea is InSims can then spot all attempts at admin commands, and if they have a list of rightful admins, they can quickly recognize someone unauthorized is trying to subvert the server, with a protective action following (kick/ban).

I hope this makes sense, and thanks for considering.

Two, I hope reasonable, InSim suggestions:

1) Could there please be somewhere a bit (or bits) saying that tweaks on the server are allowed? Maybe a bit about the host being private would be useful as well. I'm not sure, maybe these two could go to the existing race flags...

2) Could the race flags be also sent as part of IS_STA, ideally including the private/tweak bits and updated on every change (of car reset, midrace join, must pit, etc.)? There seem to be two spare bytes...

Thanks for reading/considering.

Make sure you save the file with non-standard characters as UTF-8. Then !rld and it should work... hopefully...